home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Jan 90 / MacApp.Tech$ 1⁄26⁄90 / 0490-RE TreeSaver virtual-Jan90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  4.1 KB  |  85 lines  |  [TEXT/GEOL]
  1. Item    0610592                         22-Jan-90        12:41
  2.  
  3. From:   MADA2                           MacApp Dev Assoc, Curtis Faith
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    RE:TreeSaver virtual objs.
  8.  
  9. Greg, Ed, Larry et al.,
  10.  
  11. I have implemented a virtual object scheme of sorts in TreeSaver.  I have an
  12. object that I call TNodeHandler that is responsible for maintaining, creating,
  13. storing, and retrieving nodes (TNode's).
  14.  
  15. Each node represents a Thread, Text, or a Picture.  I cannot fit all the nodes
  16. in memory and thus I need to be able to store them somewhere else.
  17.  
  18. I use insideOut as a storage manager and thus can do all sorts of nifty
  19. searches and indexing while also being able to have multi-user access to the
  20. set of potential node objects.
  21.  
  22. When a part of TreeSaver needs to get some node or list of nodes it makes a
  23. request to the TNodeHandler object.  TNodeHandler returns the TNode's that meet
  24. the request.  There are methods that return a TNode with a given ID (longint
  25. corresponding to InsideOut's Record ID), all the TNode's that have a parent of
  26. a given ID, all nodes with a date greater than a certain date and a certain
  27. type, and a few others.
  28.  
  29. TNodeHandler has a LRU cache of at least n TNode's that it keeps in memory.  It
  30. looks at the cache first for all requests.  This has 2 benefits, it allows one
  31. to have quick access to TNode's that are frequently used, and it also allows
  32. one to have only one Object for a given disk object.  If one merely retrieved
  33. the data from the disk and then created a TNode for it one might have 5 TNode
  34. objects each representing one specific node in the theoretical (disk)
  35. structure.
  36.  
  37. This later point substantially facilitates having several different views with
  38. the same node in each of them.  I keep a reference count for each of the
  39. objects and if one of the views changes some aspect of that object and its
  40. refCount is greater than 1, I send a TNodeChanged(changedNode: TNode); message
  41. to each of the views that contains nodes.  There are several other advantages
  42. (besides reduced memory requirements) to having only one object that are a bit
  43. more complex to describe.
  44.  
  45. The cache (a modified TList) will flush (essentially Free) any objects that
  46. have a refCount of 0 and are not among the n most recently used Objects.  Thus
  47. one can have more than n objects in memory if they are all actually referenced.
  48.  
  49. The cache is written out to disk when TreeSaver terminates and read in when it
  50. starts up, but the data is updated into the actual database whenever any
  51. changes are made, thus the cache never contains data that is newer than the
  52. database copy.
  53.  
  54. Each Node contains a handle that represents the actual data, the text of the
  55. Threads, text or the PICT information.  These are only read in when an action
  56. that requires the data itself is called for.  Thus normally a TNode is not a
  57. large amount of data.  For example one might have a list of TNodes that
  58. represent the most recent set of threads.  Unless one needs to display the
  59. actual thread there is no need to keep the data for that thread in memory.
  60.  
  61.  The data is accessed via a call to GetNodeData a function which returns a
  62. Handle representing the data for the node.  GetNodeData checks to see if the
  63. data field of the object is NIL in which case it will read it in and increment
  64. the dataRefCount field.  The data is also automatically decompressed if it was
  65. compressed.
  66.  
  67. A method FreeNodeData is called whenever a TNode no-longer needs to have its
  68. data in memory.  This decrements the dataRefCount and Frees the data if it is
  69. 0.
  70.  
  71. This scheme allows one to have a potentially unlimited number of TNode objects
  72. that can be accessed while not clogging up the memory manager with a lot of
  73. unused handles.
  74.  
  75. The performance of the above scheme seems to be entirely satisfactory and can
  76. be improved with certain optimizations.
  77.  
  78. I am writing an article which should appear in the next issue of FrameWorks
  79. about TreeSaver and its underlying data structures that will explain the above
  80. in more detail.  I am also going to publish the source code for TreeSaver
  81. through the developers association.
  82.  
  83. - Curtis
  84.  
  85.